Screensharing is a technique that enables one hosting computing device, which for a non-limiting example, can be a associated with a presenter at a conference call, to share content rendered on its screen, either synchronously or a synchronously, with one or more other computing devices located remotely over a communication network, which for a non-limiting example, can be associated with one or more viewers/listeners at the conference call. For the hosting computing device, screensharing implementations typically include capture of the rendered content on the screen, compression of the captured screen content for transmission, and transmission of the compressed screen content to the computing devices of the remote computing devices over the network. For each of the remote computing devices, screensharing implementations typically include receiving the compressed screen content, decompression, and display of the screen content on a display of the remote computing device.
Typically the shared screen content can be but is not limited to applications running on the computing device, such as MS Word, PowerPoint, and web browsers, etc. This type of content may contain one or more of textual images (such as simple text) and static images (such as solid background and continuous-tone images) and is referred to here in as “non-video content” to be distinguished from “video content”. Non-video content does change and can change frequently (although may not be as frequently as video content), but unlike video content, non-video content contains fine details (e.g., text and icons) that need to be preserved at the highest possible image quality in order to be reproduced very accurately on the screens of the remote computing devices.
Increasingly, the content rendered on the screen can be multimedia in nature, and video content (such as a video clip, an animation or simulation application) is becoming more important since computers and the Internet have become fast enough to make video content a frequently used type of content. As a result, there is an increasing need to be able to share video content in addition to the traditional non-video content. Existing screen capture and compression techniques are optimized and very well suited for non-video content, which requires high fidelity but low frequency and irregular updates. Unlike the textual and static images, however, video content rendered on the screen is dynamic in nature and changes constantly over time. Consequently, the video content on the screen needs to be captured and compressed at high regular frame/screenshot rate while pixel-accuracy less important. While the non-video content optimized capture and compression approaches can certainly encode the video content, they are typically very inefficient at it. For a non-limiting example, existing static-content optimized capture approaches may only be able to reproduce low frequency, e.g., 1-3 frames/screenshots per second (fps), over a communication link 1 M bit/second in bandwidth since they strive to maximize image fidelity at the expense of update frequency. If applied to video content that need to be captured at a high frequency. e.g., at 30 fps, for real time transmission since, such approaches would result in high bitrates (e.g., 10M bits/second) of compressed data, placing a prohibitively heavy burden on the processing capacity of the computer device performing the compression, and the bandwidth of the communication network transmitting the compressed data. For another non-limiting example, existing image compression approaches such as JPEG and PNG and especially sophisticated derivatives that combine the two make them very good choices for high fidelity compression of the non-video content but not fast compression of the video content. Video compression via a video codec such as H.264, on the other hand, is capable of compressing the video content 10 or more times efficient than an image compression approach, but is not suitable for compression of the non-video content since that would result in unacceptable image quality. For a non-limiting example, 8 point text on a 1600×1200 screen would be unreadable.
One way to transmit and share the video content rendered on the screen is to transmit/stream it as a video file separate from the rest of content on the screen. For a non-limiting example, a file of the video content may be first uploaded by a sender to a central storage location, and then downloaded to and played back at computing devices of the intended viewers in synchronization with the rest of the screenshot shared with the viewers. This approach, however, only works if the sender has control of the video file or has it prepared ahead of time before sharing it with others and the computing devices of the sender and the viewers must have various kinds of video codecs pre-installed in order to support the playback of the video file. The approach does not work when no file for the video content to be shared is readily available, for non-limiting examples, when a video is embedded in a PowerPoint presentation or played inside a webpage like a YouTube® video, or any Adobe Flash® video/animation/simulation.
The foregoing examples of the related art and limitations related therewith are intended to be illustrative and not exclusive. Other limitations of the related art will become apparent upon a reading of the specification and a study of the drawings.